Hi, the first try seems good. After updating and restarting, my ESP32-S3 connected to my nearby router, which has the strongest signal (-43dBm). This was a new experience, as the Nuki Hub had previously always connected to the first available AP instead of the one with the best signal.

I will continue watching and testing it. Can you maybe also add the authName fix for further testing, please?

Thank you very much!

PS: Also a second try to bring the AP temporarily closer to the ESP32 also worked.

Yesterday evening, it was probably just luck. I have just made another attempt by placing the ESP32 next to an AP and turning the ESP32 on and off. After three tries, the ESP32 didn't connect to the AP, but instead connected to a more distant router or another AP (so far, there have been no authName errors).

System Information:

Nuki Hub version: 8.33
run: true
confVersion: 833
deviceId: 439958162
deviceIdOp: 439958162
nukiId: ***
nukidOp: 
mqttbroker: 192.168.2.164
mqttport: 1883
mqttuser: ***
mqttpass: ***
mqttlog: false
checkupdates: false
lockena: true
lockpin: 1
mqttpath: nuki
openerena: false
openerpin: 
openercont: false
mqttoppath: 
maxkpad: 
opmaxkpad: 
mqttca: 
mqttcrt: 
mqttkey: 
hassdiscovery: 
hassConfigUrl: 
dhcpena: false
ipaddr: 192.168.2.188
ipsub: 255.255.255.0
ipgtw: 192.168.2.1
dnssrv: 
nwhw: 1
nwwififb: false
rssipb: 60
nwbestrssi: true
hostname: nukihub
nettmout: 240
restdisc: true
rstbcn: 60
lockStInterval: 1800
configInterval: 3600
batInterval: 1800
kpInterval: 1800
kpCntrlEnabled: true
aclConfig: false
kpInfoEnabled: false
aclLckOpn: 
tcCntrlEnabled: false
tcInfoEnabled: false
accLvl: 
regAsApp: false
nrRetry: 3
rtryDelay: 100
crdusr: ***
crdpass: ***
pubAuth: false
pubdbg: false
prdtimeout: 60
hasmac: false
macb0: 
macb1: 
macb2: 
latest: 
MQTT connected: Yes
Lock firmware version: 3.9.5
Lock hardware version: 5.12
Lock paired: Yes
Lock PIN set: Yes
Lock has door sensor: No
Lock has keypad: No
Lock ACL (Lock): Allowed
Lock ACL (Unlock): Disallowed
Lock ACL (Unlatch): Disallowed
Lock ACL (Lock N Go): Disallowed
Lock ACL (Lock N Go Unlatch): Disallowed
Lock ACL (Full Lock): Disallowed
Lock ACL (Fob Action 1): Disallowed
Lock ACL (Fob Action 2): Disallowed
Lock ACL (Fob Action 3): Disallowed
Network device: Built-in Wi-Fi
Uptime: 5 minutes
Heap: 158736
Stack watermarks: nw: 5756, nuki: 276, pd: 92
Restart reason FW: NotApplicable
Restart reason ESP: ESP_RST_POWERON: Reset due to power-on event.

You do seem to have it configured correctly so this will need some more debugging on my end.

It seems as you mentioned that ESP's only connect to the first BSSID/AP they find and not necessarily the best one. An ESP with a LAN connection is unfortunately not possible in my place (too far away because of BLE).

I hope you can find a solution when debugging. I would be happy to test other firmwares with my test ESP32-S3.

btw: Does it also make sense to talk via Discord? The link under "About" seems to have expired. Otherwise I prefer Matrix (e.g. Element), where I have created a Nuki-Hub room: #nuki-hub:tchncs.de

Hi, this is the link to our discord:

https://discord.gg/24HxpGBJ

This one should work: esp32-s3-assets.zip

In the first version best BSSID was only selected on the very first connection to the network and not on every connection after (including after restarts). This is now fixed.

Tested with debugging enabled (off again in this binary) on my own ESP32-S3. With debugging on the BSSID selection process can be followed and in my testing worked perfectly.

The currently selected BSSID can also be viewed on the info page in the web configurator now.

Yes, indeed, your second version works great!! I placed the ESP32-S3 near three different APs, and the Nuki-Hub connected to them as expected because it provides the best signal.

On the info page I can see the MAC BSSID of the AP for verification. I like that, thank you very much!

@iranl could you share a version of this to test that is in par with 8.34 just released?

Amazing work. Thanks a lot.

Binaries of current master (8.34 + #343) + this PR:

esp32-assets.zip
esp32-s3-assets.zip
esp32-c3-assets.zip
esp32solo1-assets.zip

@iranl my observations/questions:

1. does ESP32 support 802.11r for AP roaming?
   (update: it seems it does, see here)
2. I would call the option "Enable/Disable AP Roaming".
3. Would it make sense to implement a configurable RSSI threshold so user decides when to trigger the roaming. Without that, in specific cases the risk is that it bounces back and forth between 2 APs that have similar RSSIs that fluctuate.

1. I believe 802.11r was added to ESP-IDF in v5. As Arduino Core 2.0.15 is based on ESP-IDF v4.4.7 I don't believe 802.11r is currently supported
2. It's not really a roaming option. Before this PR Nuki Hub just connected to the first AP it encounters that broadcasts the configured SSID. This could randomly be a very far AP with a bad signal or a very near AP with a good signal. It would not check for additional available AP's and it would not necessarily connect to the strongest AP. This option changes that behaviour and check for multiple AP's before selecting the one with the strongest signal and connect to that and stay connected to that until the connection is lost.. I would say this is perfectly fine for the use case of Nuki Hub. It's a static device and so are the AP's. There is no real reason for 802.11r in this case.
3. See 2., there is no risk of this as Nuki Hub only connects to the strongest available AP at the time of connection and will stay connected to this AP until it loses this connection completely (e.g. because of the WIFI stack failing or the AP rebooting/shutdown). Your other config settings will determine if Nuki Hub will reboot at this time and reconnect or try to reconnect without rebooting. In both cases it will look for the strongest AP again and connect to that.

2. This option changes that behaviour and check for multiple AP's before selecting the one with the strongest signal and connect to that and stay connected to that until the connection is lost

Ok, I thought it constantly checked for the AP with the strongest signal, so it only does it on connection, and obviously when it needs to reconnect (reboots, etc.), correct? It doesn't search for strongest signal when already connected.

Yes, WifiManager is only active during the connection phase, and then quits. It's a frontend to configure the ESPs Wifi stack, whatever else is handled within the stack.